Fix overflow caused by default spin timeout #1563

Flova · 2025-12-09T18:25:27Z

Description

Previously, the max() value of the steady time was used as the default deadline. In some environments this results in overflows in the underlying pthread_cond_timedwait call, which waits for the conditional variable in the events queue implementation. Consequently, this lead to undefined behavior and freezes in the executor. Reducing the deadline significantly helped, but using cv.wait instead of cv_.wait_until seems to be the cleaner solution.

Did you use Generative AI?

No

Additional Information

traversaro · 2025-12-11T10:54:24Z

To give a bit more context, in a nutshell it seems that passing std::chrono::steady_clock::time_point::max() to std::condition_variable::wait_until is allowed in theory, but quite problematic in practice, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113327 .

fujitatomoya

lgtm with green CI.

fujitatomoya · 2025-12-12T00:20:09Z

Pulls: #1563
Gist: https://gist.githubusercontent.com/fujitatomoya/e4e5bc6068d3e325f078d39bae24d680/raw/f605c9888dbd10e19688d128f55e00d8f395791c/ros2.repos
BUILD args: --packages-above-and-dependencies rclpy
TEST args: --packages-above rclpy
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/17758

Linux
Linux-aarch64
Linux-rhel
Windows

Flova · 2025-12-12T08:56:10Z

I think most of the CI failures are unrelated right?

Regarding the failing test on windows:
The test fails because threading.Event().wait(0.1) # Simulate some work only takes ~93ms. Instead of >=100ms and >200ms. I suspect this is because of the low timer resolution on windows (10-16 ms), leading to a slightly earler trigger, which aligns with the observed behavior. Linux has a much higher timer resolution by default. I would suggest we either increase the timer resolution (Idk if this is possible from Python) or add some tolerances.

Also while being related to the changes in this PR, these changes should not modify the behavior when an explicit timeout is given for the executor, which is the case here. So it is kind of interesting that this fails.

Flova · 2025-12-12T09:15:00Z

A quick minimal test without ROS on Windows 11 and Python 3.12 shows that the logic used in the test is flawed on Windows:

>>> t1 = time.monotonic(); threading.Event().wait(0.1); print(time.monotonic() - t1)
False
0.125
>>> t1 = time.monotonic(); threading.Event().wait(0.1); print(time.monotonic() - t1)
False
0.10900000000037835
>>> t1 = time.monotonic(); threading.Event().wait(0.1); print(time.monotonic() - t1)
False
0.10900000000037835
>>> t1 = time.monotonic(); threading.Event().wait(0.1); print(time.monotonic() - t1)
False
0.10900000000037835
>>> t1 = time.monotonic(); threading.Event().wait(0.1); print(time.monotonic() - t1)
False
0.09400000000005093

but it is not strictly an issue of the Event().wait() as we have a similar issue with time.sleep() which uses a high res timer. This is a result of time.monotonic() also only having ~15ms resolution on Windows....

>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.10999999999967258
>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.10899999999946886
>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.09400000000005093
>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.10999999999967258
>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.10900000000037835
>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.10899999999946886
>>> t1 = time.monotonic(); time.sleep(0.1); print(time.monotonic() - t1)
0.10899999999946886

>>> for i in range(100): time.monotonic()
4984.406
4984.406
4984.406
4984.406
4984.406
4984.406
4984.406
4984.406
4984.406
4984.406
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
4984.421
...

traversaro · 2025-12-12T09:34:20Z

The test fails because threading.Event().wait(0.1) # Simulate some work only takes ~93ms. Instead of >=100ms and >200ms. I suspect this is because of the low timer resolution on windows (10-16 ms), leading to a slightly earler trigger, which aligns with the observed behavior.

Slightly unrelated, but the 10/16 ms scheduler resolution on Windows can be avoided by calling timeBeginPeriod, see:

Flova · 2025-12-12T09:50:43Z

Slightly unrelated, but the 10/16 ms scheduler resolution on Windows can be avoided by calling timeBeginPeriod, see:

But this is only possible in the underlying C implementation right?

Flova · 2025-12-12T09:57:09Z

Using time.sleep() and time.perf_counter() fixes the issue, as both use a more accurate timer:

>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10133029999997234
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10042189999967377
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10094169999956648
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10087759999987611
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10047479999957432
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10064109999984794
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10096969999995054
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.1007225000003018
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)
0.10061409999980242
>>> t1 = time.perf_counter(); time.sleep(0.1); print(time.perf_counter() - t1)

traversaro · 2025-12-12T09:57:38Z

Slightly unrelated, but the 10/16 ms scheduler resolution on Windows can be avoided by calling timeBeginPeriod, see:

But this is only possible in the underlying C implementation right?

That is where perhaps it starts being OT, but one can write a small class with constructors and destructors like:

WindowsSchedulerBooster()
{
#if defined(_WIN32)
    // Only affects Windows systems.
    TIMECAPS tm; // Stores system timer capabilities.
    // Get the minimum timer resolution supported by the system.
    timeGetDevCaps(&tm, sizeof(TIMECAPS));
    // Set the system timer resolution to the minimum value for higher precision.
    timeBeginPeriod(tm.wPeriodMin);
#endif
}

~WindowsSchedulerBooster()
{
#if defined(_WIN32)
    // Only affects Windows systems.
    TIMECAPS tm; // Stores system timer capabilities.
    // Get the minimum timer resolution supported by the system.
    timeGetDevCaps(&tm, sizeof(TIMECAPS));
    // Restore the system timer resolution to the default value.
    timeEndPeriod(tm.wPeriodMin);
#endif
}

and wrap it in a Python bindings, so that it can be called from Python tests. Alternatively, something similar can also be done directly via ctypes. Again, this is probably out of scope here, I just want to mention it for search engines and llm to find this. :)

Flova · 2025-12-12T10:11:51Z

Slightly unrelated, but the 10/16 ms scheduler resolution on Windows can be avoided by calling timeBeginPeriod, see:

But this is only possible in the underlying C implementation right?

That is where perhaps it starts being OT, but one can write a small class with constructors and destructors like:
WindowsSchedulerBooster()
{
#if defined(_WIN32)
    // Only affects Windows systems.
    TIMECAPS tm; // Stores system timer capabilities.
    // Get the minimum timer resolution supported by the system.
    timeGetDevCaps(&tm, sizeof(TIMECAPS));
    // Set the system timer resolution to the minimum value for higher precision.
    timeBeginPeriod(tm.wPeriodMin);
#endif
}

~WindowsSchedulerBooster()
{
#if defined(_WIN32)
    // Only affects Windows systems.
    TIMECAPS tm; // Stores system timer capabilities.
    // Get the minimum timer resolution supported by the system.
    timeGetDevCaps(&tm, sizeof(TIMECAPS));
    // Restore the system timer resolution to the default value.
    timeEndPeriod(tm.wPeriodMin);
#endif
}
and wrap it in a Python bindings, so that it can be called from Python tests. Alternatively, something similar can also be done directly via ctypes. Again, this is probably out of scope here, I just want to mention it for search engines and llm to find this. :)

Cool, we should make an issue for that. For now I made an additional PR that uses perf_counter, which is already used by most other tests.

fujitatomoya · 2025-12-15T07:24:28Z

@Mergifyio rebase

Previously the max() value of the steady time was used as the default deadline. In some environments this results in overflows in the underlying pthread_cond_timedwait call, which waits for the conditional variable in the events queue implementation. Consequently, this lead to freezes in the executor. Reducing the deadline significantly helped, but using `cv.wait` instead of `cv_.wait_until` seems to be the cleaner solution. Signed-off-by: Florian Vahl <[email protected]>

mergify · 2025-12-15T07:24:56Z

rebase

✅ Branch has been successfully rebased

fujitatomoya · 2025-12-15T07:25:47Z

Linux
Linux-aarch64
Linux-rhel
Windows

Flova · 2025-12-17T11:08:11Z

Is it possible to backport this change to jazzy and kilted as well?

fujitatomoya · 2025-12-17T23:40:56Z

@Flova does this depend on #1469? in that case, we probably want to wait until backport #1560 to be merged?

Flova · 2025-12-18T07:52:41Z

No. I think you mean #1564, that one fixes an issue from #1469

fujitatomoya · 2025-12-19T02:18:02Z

@Flova ah yeah, sorry.

I have one question here about backport for jazzy and kilted before doing that.
This PR is technically ABI breaking change, i think EventsExecutor could be backported to downstream because those are just adding new APIs and Classes. so i would want to have the agreement before we are doing backport of this.

i am almost sure that, this is C++ implementation behind python EventExecutors, so almost nobody cares about the implementation details. even if implementation breaks the ABI, that is not really exposed to user application. after all, i think we can do backports to fix the issues. what do you say? @Flova @ahcorde @mjcarroll @jmachowinski @alsora

Flova · 2025-12-19T08:23:53Z

Alright. We had the same discussion in PR RoboStack/ros-jazzy#137 for the RoboStack conda packages, which already include this bugfix as a patch file. There were also some concerns regarding ABI compatibility and we came to the conclusion that it private header, which is not installed, so it should be fine. In addition to that there is also the possibility to fix this issue in a less clean way, by just adding a "magic value" that doesn't overflow as the time point. This has it's own drawbacks, but would preserve the ABI. I would still favor the backport of this PR instead of a custom solution for these distros.

jmachowinski · 2025-12-19T09:14:55Z

As nobody links against rclpy ABI compability is not an issue.

fujitatomoya · 2025-12-20T02:28:35Z

@Flova @traversaro @jmachowinski thanks for the feedback! Let's do that then!

fujitatomoya · 2025-12-20T02:28:54Z

@Mergifyio backport kilted jazzy

mergify · 2025-12-20T02:29:00Z

backport kilted jazzy

✅ Backports have been created

Details

#1567 Fix overflow caused by default spin timeout (backport #1563) has been created for branch kilted
#1568 Fix overflow caused by default spin timeout (backport #1563) has been created for branch jazzy

Previously the max() value of the steady time was used as the default deadline. In some environments this results in overflows in the underlying pthread_cond_timedwait call, which waits for the conditional variable in the events queue implementation. Consequently, this lead to freezes in the executor. Reducing the deadline significantly helped, but using `cv.wait` instead of `cv_.wait_until` seems to be the cleaner solution. Signed-off-by: Florian Vahl <[email protected]> (cherry picked from commit eddfdb6)

Previously the max() value of the steady time was used as the default deadline. In some environments this results in overflows in the underlying pthread_cond_timedwait call, which waits for the conditional variable in the events queue implementation. Consequently, this lead to freezes in the executor. Reducing the deadline significantly helped, but using `cv.wait` instead of `cv_.wait_until` seems to be the cleaner solution. (cherry picked from commit eddfdb6) Signed-off-by: Florian Vahl <[email protected]> Co-authored-by: Florian Vahl <[email protected]>

Previously the max() value of the steady time was used as the default deadline. In some environments this results in overflows in the underlying pthread_cond_timedwait call, which waits for the conditional variable in the events queue implementation. Consequently, this lead to freezes in the executor. Reducing the deadline significantly helped, but using `cv.wait` instead of `cv_.wait_until` seems to be the cleaner solution. Signed-off-by: Florian Vahl <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]>

) * Fix warnings from gcc. (#1501) Signed-off-by: Michael Carlstrom <[email protected]> * Update type_support to use new abcs Signed-off-by: Michael Carlstrom <[email protected]> * Cleanup old test cases to use new automatic inference Signed-off-by: Michael Carlstrom <[email protected]> * Add content-filtered-topic interfaces (#1506) Signed-off-by: Barry Xu <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Added lock to protect futures for multithreaded executor (#1477) Signed-off-by: brennanmk <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * EventsExecutor: Handle async callbacks for services and subscriptions (#1478) Closes #1473 Signed-off-by: Brad Martin <[email protected]> Co-authored-by: Brad Martin <[email protected]> Co-authored-by: Alejandro Hernandez Cordero <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * add spinning state for the Executor classes. (#1510) Signed-off-by: Tomoya.Fujita <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Fixes Action.*_async futures never complete (#1308) Per rclpy:1123 If two seperate client server actions are running in seperate executors the future given to the ActionClient will never complete due to a race condition This fixes the calls to rcl handles potentially leading to deadlock scenarios by adding locks to there references Co-authored-by: Aditya Agarwal <[email protected]> Co-authored-by: Jonathan Blixt <[email protected]> Signed-off-by: Jonathan Blixt <[email protected]> Co-authored-by: Alejandro Hernandez Cordero <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * remove unused 'param_type' (#1524) 'param_type' is set but never used Signed-off-by: Christian Rauch <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Changelog Signed-off-by: Alejandro Hernandez Cordero <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * 10.0.1 Signed-off-by: Michael Carlstrom <[email protected]> * Remove duplicate future handling from send_goal_async (#1532) A recent change intended to move this logic into a lock context, but actually ended up duplicating it instead. This fixes that by removing the duplicated logic outside of the lock. It also preserves the explicit typing annotation on the future. Signed-off-by: Nathan Wiebe Neufeldt <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * fix(test_events_executor): destroy all nodes before shutdown (#1538) Signed-off-by: yuanyuyuan <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * add BaseImpl Signed-off-by: Michael Carlstrom <[email protected]> * Add ImplT Support Signed-off-by: Michael Carlstrom <[email protected]> * fix changelong Signed-off-by: Michael Carlstrom <[email protected]> * Remove accidental tuple (#1542) Signed-off-by: Michael Carlstrom <[email protected]> * Allow action servers without execute callback (#1219) Signed-off-by: Tim Clephas <[email protected]> * add : get clients, servers info (#1307) Signed-off-by: Minju, Lee <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * 10.0.2 Signed-off-by: Michael Carlstrom <[email protected]> * update tests Signed-off-by: Michael Carlstrom <[email protected]> * ParameterEventHandler support ContentFiltering (#1531) * ParameterEventHandler support ContentFiltering Signed-off-by: Barry Xu <[email protected]> * Address review comments Signed-off-by: Barry Xu <[email protected]> --------- Signed-off-by: Barry Xu <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Fix issues with resuming async tasks awaiting a future (#1469) Signed-off-by: Błażej Sowa <[email protected]> Signed-off-by: Nadav Elkabets <[email protected]> Co-authored-by: Nadav Elkabets <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * 10.0.3 Signed-off-by: Michael Carroll <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Increase clock accuracy (#1564) Signed-off-by: Florian Vahl <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Use unconditional wait when possible. (#1563) Previously the max() value of the steady time was used as the default deadline. In some environments this results in overflows in the underlying pthread_cond_timedwait call, which waits for the conditional variable in the events queue implementation. Consequently, this lead to freezes in the executor. Reducing the deadline significantly helped, but using `cv.wait` instead of `cv_.wait_until` seems to be the cleaner solution. Signed-off-by: Florian Vahl <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Remove default from switch with enum, so that compiler warns. (#1566) Signed-off-by: Tomoya Fujita <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Fix parameter parsing for unspecified target nodes (#1552) Signed-off-by: Barry Xu <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Improve the compatibility of processing YAML parameter files (#1548) Signed-off-by: Barry Xu <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Improve wildcard parsing and optimize the logic for parsing YAML para… (#1571) Signed-off-by: Barry Xu <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Expose action graph functions as Node class methods. (#1574) * Expose action graph functions as Node class methods. Signed-off-by: Tomoya Fujita <[email protected]> * address review comments to keep the warning consistent. Signed-off-by: Tomoya.Fujita <[email protected]> --------- Signed-off-by: Tomoya Fujita <[email protected]> Signed-off-by: Tomoya.Fujita <[email protected]> * Fix performance bug in MultiThreadedExecutor (hopefully) (#1547) Signed-off-by: Michael Tandy <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * Changelog Signed-off-by: Alejandro Hernandez Cordero <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> * 10.0.4 Signed-off-by: Michael Carlstrom <[email protected]> * use Msg over BaseMessage Signed-off-by: Michael Carlstrom <[email protected]> * Use Srv over BaseService Signed-off-by: Michael Carlstrom <[email protected]> * Use Action over BaseAction Signed-off-by: Michael Carlstrom <[email protected]> * lint Signed-off-by: Michael Carlstrom <[email protected]> * Update rclpy/rclpy/type_support.py Co-authored-by: Christophe Bedard <[email protected]> Signed-off-by: Michael Carlstrom <[email protected]> --------- Signed-off-by: Michael Carlstrom <[email protected]> Signed-off-by: Barry Xu <[email protected]> Signed-off-by: brennanmk <[email protected]> Signed-off-by: Brad Martin <[email protected]> Signed-off-by: Tomoya.Fujita <[email protected]> Signed-off-by: Christian Rauch <[email protected]> Signed-off-by: Alejandro Hernandez Cordero <[email protected]> Signed-off-by: Nathan Wiebe Neufeldt <[email protected]> Signed-off-by: yuanyuyuan <[email protected]> Signed-off-by: Tim Clephas <[email protected]> Signed-off-by: Minju, Lee <[email protected]> Signed-off-by: Barry Xu <[email protected]> Signed-off-by: Błażej Sowa <[email protected]> Signed-off-by: Nadav Elkabets <[email protected]> Signed-off-by: Michael Carroll <[email protected]> Signed-off-by: Florian Vahl <[email protected]> Signed-off-by: Florian Vahl <[email protected]> Signed-off-by: Tomoya Fujita <[email protected]> Signed-off-by: Tomoya.Fujita <[email protected]> Signed-off-by: Michael Tandy <[email protected]> Co-authored-by: Chris Lalancette <[email protected]> Co-authored-by: Barry Xu <[email protected]> Co-authored-by: Brennan Miller-Klugman <[email protected]> Co-authored-by: Brad Martin <[email protected]> Co-authored-by: Brad Martin <[email protected]> Co-authored-by: Alejandro Hernandez Cordero <[email protected]> Co-authored-by: Tomoya Fujita <[email protected]> Co-authored-by: Jonathan <[email protected]> Co-authored-by: Christian Rauch <[email protected]> Co-authored-by: Nathan Wiebe Neufeldt <[email protected]> Co-authored-by: Yuyuan Yuan <[email protected]> Co-authored-by: Tim Clephas <[email protected]> Co-authored-by: Minju, Lee <[email protected]> Co-authored-by: Błażej Sowa <[email protected]> Co-authored-by: Nadav Elkabets <[email protected]> Co-authored-by: Michael Carroll <[email protected]> Co-authored-by: Florian Vahl <[email protected]> Co-authored-by: Michael Tandy <[email protected]> Co-authored-by: Christophe Bedard <[email protected]>

Flova changed the title ~~Switch events queue timeout from deadline to duration and use unconditional wait when possible~~ Use unconditional wait when possible Dec 10, 2025

Flova force-pushed the rolling branch from ab1662d to 88f355e Compare December 10, 2025 08:54

Flova changed the title ~~Use unconditional wait when possible~~ Fix overflow caused by default spin timeout Dec 10, 2025

Flova added a commit to Flova/ros-jazzy that referenced this pull request Dec 10, 2025

Add ros2/rclpy#1563

d16e085

Flova mentioned this pull request Dec 10, 2025

Fix rclpy events executor RoboStack/ros-jazzy#137

Merged

Flova changed the title ~~Fix overflow caused by default spin timeout~~ Fix invalid syscall caused by default spin timeout Dec 10, 2025

Flova changed the title ~~Fix invalid syscall caused by default spin timeout~~ Fix overflow caused by default spin timeout Dec 10, 2025

Flova mentioned this pull request Dec 10, 2025

Use Pixi bit-bots/bitbots_main#730

Merged

3 tasks

fujitatomoya approved these changes Dec 12, 2025

View reviewed changes

Flova mentioned this pull request Dec 12, 2025

👩‍🌾 Regression on TestExecutor.test_create_task_coroutine_wake_from_another_thread #1562

Closed

Flova mentioned this pull request Dec 12, 2025

Fix windows regression: Increase clock accuracy #1564

Merged

fujitatomoya force-pushed the rolling branch from 88f355e to 7fe657d Compare December 15, 2025 07:24

Flova mentioned this pull request Dec 15, 2025

Increase internal Windows timer rates #1565

Open

ahcorde merged commit eddfdb6 into ros2:rolling Dec 16, 2025
3 checks passed

mergify bot mentioned this pull request Dec 20, 2025

Fix overflow caused by default spin timeout (backport #1563) #1567

Merged

mergify bot mentioned this pull request Dec 20, 2025

Fix overflow caused by default spin timeout (backport #1563) #1568

Merged

Flova added a commit to bit-bots/robostack-jazzy-custom-pkgs that referenced this pull request Dec 29, 2025

Add ros2/rclpy#1563

a1ab383

Flova mentioned this pull request Jan 19, 2026

Fix rclpy events executor RoboStack/ros-kilted#40

Open

Fix overflow caused by default spin timeout #1563

Fix overflow caused by default spin timeout #1563

Conversation

Flova commented Dec 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Did you use Generative AI?

Additional Information

Uh oh!

traversaro commented Dec 11, 2025

Uh oh!

fujitatomoya left a comment

Choose a reason for hiding this comment

Uh oh!

fujitatomoya commented Dec 12, 2025

Uh oh!

Flova commented Dec 12, 2025

Uh oh!

Flova commented Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traversaro commented Dec 12, 2025

Uh oh!

Flova commented Dec 12, 2025

Uh oh!

Flova commented Dec 12, 2025

Uh oh!

traversaro commented Dec 12, 2025

Uh oh!

Flova commented Dec 12, 2025

Uh oh!

fujitatomoya commented Dec 15, 2025

Uh oh!

mergify bot commented Dec 15, 2025

✅ Branch has been successfully rebased

Uh oh!

fujitatomoya commented Dec 15, 2025 • edited by ahcorde Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Flova commented Dec 17, 2025

Uh oh!

fujitatomoya commented Dec 17, 2025

Uh oh!

Flova commented Dec 18, 2025

Uh oh!

fujitatomoya commented Dec 19, 2025

Uh oh!

Flova commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmachowinski commented Dec 19, 2025

Uh oh!

fujitatomoya commented Dec 20, 2025

Uh oh!

fujitatomoya commented Dec 20, 2025

Uh oh!

mergify bot commented Dec 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Backports have been created

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Flova commented Dec 9, 2025 •

edited

Loading

Flova commented Dec 12, 2025 •

edited

Loading

fujitatomoya commented Dec 15, 2025 •

edited by ahcorde

Loading

Flova commented Dec 19, 2025 •

edited

Loading

mergify bot commented Dec 20, 2025 •

edited

Loading